Summary

Fixes editing in tables with composite primary keys. Previously, UPDATE and DELETE statements only used the first PK column in the WHERE clause, causing all rows sharing that value to be affected instead of just the target row.

Root cause: The entire editing pipeline modeled primary keys as primaryKeyColumn: String? (single column). Schema detection used .first(where: { $0.isPrimaryKey }) which silently dropped all but the first PK column.

Changes

Composite PK support (15 source files)

Thread primaryKeyColumns: [String] through the pipeline, replacing primaryKeyColumn: String?:

• TableSchema — primaryKeyColumns: [String], computed primaryKeyColumn for backward compat
• QueryTab, TabPendingChanges — same rename
• DataChangeManager — primaryKeyColumns: [String] + configureForTable signature
• SQLStatementGenerator — UPDATE: loops all PK columns → WHERE a = ? AND b = ?; batch DELETE: (a = ? AND b = ?) OR (a = ? AND b = ?)
• MainContentCoordinator+QueryHelpers — .filter { $0.isPrimaryKey }.map(\.name) instead of .first(where:)?.name
• DataGridView, DataGridCoordinator — primaryKeyColumns: [String] with computed primaryKeyColumn
• RowOperationsManager — sets __DEFAULT__ on all PK columns when duplicating rows

Structure view safe mode bypass (1 file)

TableStructureView+Schema.swift — executeSchemaChanges() now checks connection.safeModeLevel.blocksAllWrites before executing DDL

discardChanges() stale state (1 file)

DataChangeManager.swift — added missing changedRowIndices.removeAll()

Tests (14 files)

• New: SQLStatementGeneratorCompositePKTests.swift — 22 test cases
• Updated: 13 existing test files for primaryKeyColumns: [String] parameter rename

Test coverage (22 new tests)

How to reproduce the original bug

CREATE TABLE order_items (
    order_id INT, product_id INT, quantity INT,
    PRIMARY KEY (order_id, product_id)
);
INSERT INTO order_items VALUES (1,100,2), (1,200,3), (1,300,1);

Edit quantity of row (1, 200) → Save → Before fix: all 3 rows updated. After fix: only (1, 200) updated.

Test plan

• Create composite PK table, edit one row → verify only that row updates
• Delete one row in composite PK table → verify only that row deleted
• Preview SQL (Cmd+Shift+P) → verify WHERE has all PK columns with AND
• Verify single-PK tables still work correctly
• Verify no-PK tables use all-column fallback
• Set connection to read-only → open Structure view → try Save → verify blocked
• Discard changes → verify no stale row highlighting